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Abstract 

Previously,  we  developed  a  type  system  to  ensure  secure 
information  flow  in  a  sequential,  imperative  programming 
language  [VSI96].  Program  variables  are  classified  as  ei¬ 
ther  high  or  low  security;  intuitively,  we  wish  to  prevent 
information  from  flowing  from  high  variables  to  low  vari¬ 
ables.  Here,  we  extend  the  analysis  to  deal  with  a  multi¬ 
threaded  language.  We  show  that  the  previous  type  system 
is  insufficient  to  ensure  a  desirable  security  property  called 
noninterference.  Noninterference  basically  means  that  the 
final  values  of  low  variables  are  independent  of  the  initial 
values  of  high  variables.  By  modifying  the  sequential  type 
system,  we  are  able  to  guarantee  noninterference  for  con¬ 
current  programs.  Crucial  to  this  result,  however,  is  the  use 
of  purely  nondeterministic  thread  scheduling.  Since  imple¬ 
menting  such  scheduling  is  problematic,  we  also  show  how 
a  more  restrictive  type  system  can  guarantee  noninterfer¬ 
ence,  given  a  more  deterministic  (and  easily  implementable) 
scheduling  policy,  such  as  round-robin  time  slicing.  Finally, 
we  consider  the  consequences  of  adding  a  clock  to  the  lan¬ 
guage. 

1  Introduction 

The  success  of  mobile  code  technologies  depends  in  large 
part  on  what  kinds  of  security  guarantees  can  be  made  for 
clients  executing  the  code.  Among  the  concerns  here  is  en¬ 
suring  that  code  respects  a  client’s  privacy,  so  that  sensitive 
information  is  not  improperly  disclosed.  Current  software 
approaches  to  security  address  the  issue  of  protecting  pri¬ 
vacy  by  introducing  protection  domains  and  access  privi¬ 
leges.  The  basic  idea  is  to  specify,  via  a  security  policy,  a 
set  of  privileges  for  a  piece  of  code  based  on  its  digital  sig¬ 
nature.  A  check  is  then  made  for  a  certain  access  privilege 
when  the  code  attempts  to  cross  a  domain  boundary,  say 
for  example  if  it  attempts  to  access  the  local  file  system.  If 
the  privilege  has  been  granted,  execution  proceeds.  Keep 
in  mind  that  the  decision  is  made  here  against  a  security 
policy  for  the  code’s  signature,  not  the  code  itself.  This  is 
the  approach  taken  in  the  security  architecture  of  the  Java 
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Developer’s  Kit  (JDK)  1.2  [GMPS97]  and  in  the  extended 
stack  introspection  proposal  of  [WBDF97]. 

But  suppose  we  can  prove  that  a  program  satisfies  a  se¬ 
cure  information  flow  property  that  guarantees  that  the  pro¬ 
gram  respects  private  information.  Then  there  is  no  need  to 
check  at  runtime  whether  the  code  has  permission  to  read 
private  information;  we  can  simply  trust  it,  since  the  prop¬ 
erty  guarantees  that  the  information  will  not  be  improperly 
disclosed.  This  is  the  approach  taken  in  this  paper.  We  are 
interested  in  developing  a  type  system  for  a  concurrent  pro¬ 
gramming  language  and  exploring  the  secure-flow  properties 
that  can  be  shown  to  hold  for  all  well-typed  programs.  With 
such  a  type  system,  code  can  be  type  checked  for  secure-flow 
violations  just  once.  Code  that  type  checks  can  be  allowed 
to  run  and  access  private  information  without  any  further 
checks.1  Type  checking  might  be  done  by  a  client’s  security 
architecture.  Another  way  it  might  be  done  is  at  a  code  cer¬ 
tification  site.  For  example,  efforts  are  underway  at  some 
companies  in  the  U.S.  to  “certify”  the  security  of  Java  com¬ 
pilation  units  used  in  electronic  commerce  servers.  (It  is 
understandable  why  consumer  confidence  is  low  here  given 
the  rash  of  stolen  credit  card  numbers  despite  the  use  of 
encryption.)  Such  a  site  might  apply  a  type  checker  as  an 
initial  step  in  certifying  code. 

This  paper  continues  our  earlier  work  [VSI96,  VS97b, 
VS97a]  on  the  relationship  between  typing,  security  proper¬ 
ties,  and  semantics,  but  now  in  a  concurrent  setting.  The 
paper  presents  the  following  results: 

1.  We  show  that  the  type  system  of  [VSI96]  is  no  longer 
sufficient  to  guarantee  a  desirable  security  property, 
called  noninterference,  if  we  add  threads  to  our  lan¬ 
guage.  The  noninterference  property  is  intended  to 
assert  that  information  cannot  flow  from  high  vari¬ 
ables  to  low  variables;  basically,  it  says  that  the  final 
values  of  low  variables  are  independent  of  the  initial 
values  of  high  variables. 

2.  We  show  that  the  noninterference  property  can  be  re¬ 
stored  in  a  multi-threaded  language  by  requiring  the 
guards  of  while  loops  to  have  type  low  and  by  re¬ 
quiring  while  loops  themselves  to  have  type  low  cmd. 
(Conditionals  do  not  need  to  be  restricted.)  This  is 
the  main  result  of  the  paper. 

3.  Crucial  to  the  above  result,  however,  is  the  use  of 
purely  nondeterministic  thread  scheduling.  It  is  not 

1  We  do  not  mean  to  suggest  that  such  a  type  system  would  address 
all  security  concerns.  Integrity  properties,  for  instance,  might  well  be 
best  handled  by  code  signing. 
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clear  how  such  scheduling  can  be  implemented  in  prac¬ 
tice.  We  show  that  with  more  deterministic  schedul¬ 
ing,  such  as  round-robin  time  slicing  (which  is  used  in 
the  implementation  of  Java  threads  in  Windows  NT 
4.0),  the  noninterference  property  does  not  hold.  We 
show  that  noninterference  can  be  restored,  regardless 
of  the  scheduling  policy  used,  by  also  requiring  the 
guards  of  conditionals  to  have  type  low. 

4.  We  consider  adding  a  clock  to  the  language.  We  show 
that  unless  the  clock  is  given  type  high ,  noninterference 
is  not  preserved. 

The  remainder  of  the  paper  is  organized  as  follows.  In 
Section  2,  we  give  an  example  that  shows  that  the  type  sys¬ 
tem  of  [VSI96]  is  insufficient  to  ensure  noninterference  in  a 
multi-threaded  language.  In  Sections  3  and  4,  we  formally 
define  the  semantics  of  our  multi-threaded  language  and  its 
type  system.  Then,  in  Section  5,  we  prove  that  the  type  sys¬ 
tem  guarantees  the  noninterference  property.  In  Section  6, 
we  explore  how  adding  a  clock  to  the  language  affects  the 
noninterference  property.  In  Section  7,  we  consider  the  con¬ 
sequences  of  using  a  less  nondeterministic  (but  more  imple- 
ment.able)  semantics  of  concurrency.  In  Section  8,  we  discuss 
some  interactions  among  the  noninterference  property  and 
language  semantics.  Finally,  in  Section  9,  we  discuss  some 
related  work. 

2  The  Effect  of  Threads  on  Noninterference 

Recently,  the  authors  showed  that  a  Denning-style  secure- 
flow  analysis  of  imperative  programs  can  be  formulated  as  a 
type  system  [VSI96].  For  example,  suppose  that  we  wish  to 
support  two  security  classes,  L  (low)  and  H  (high).  Then 
we  can  use  these  security  classes  as  the  types  of  program 
variables.  Thus,  for  variables  x  and  y,  we  can  say  x  :  H  to 
indicate  that  x  holds  high-security  information  and  y  :  L  to 
indicate  that  y  holds  low-security  information.  And  then  an 
improper  assignment  like  y  :=  x  can  be  caught  as  a  type 
error.  Note,  however,  that  the  opposite  assignment  x  :=  y 
should  be  allowed;  to  deal  with  this  we  introduce  subtyping 
into  our  type  system  and  say  that  L  C  H.  More  subtly,  the 
type  system  must  also  guard  against  implicit  information 
flows,  as  seen  in  a  program  like 

if  even(x)  then  y  :=  0  else  y  :=  1, 

which  indirectly  copies  the  last  bit  of  x  into  y.  To  deal 
with  such  implicit  flows,  the  type  system  also  classifies  pro¬ 
gram  commands  as  having  either  type  H  cmd  or  L  cmd ; 
intuitively,  a  command  of  type  H  cmd  cannot  transmit  any 
information  to  L  variables  and  hence  can  safely  be  used  in 
the  branches  of  a  conditional  whose  guard  has  type  H. 

In  [VSI96],  it  is  shown  that  the  type  system  ensures  that 
every  well-typed  program  c  satisfies  a  noninterference  prop¬ 
erty,  which  can  be  described  as  follows:  suppose  that  y  and 
v  are  two  memories  that  agree  on  all  L  variables  and  that  c 
can  be  run  successfully  starting  from  both  y  and  v,  yielding 
final  memories  y  and  v  .  Then  y  and  v'  also  agree  on  all 
L  variables.  Intuitively,  this  means  that  information  cannot 
“leak”  from  H  variables  to  L  variables,  since  the  final  val¬ 
ues  of  L  variables  are  independent  of  the  initial  values  of  H 
variables.2  Furthermore,  programs  can  be  checked  automat¬ 
ically  for  type  correctness,  by  doing  type  inference  [VS97b]. 

2It  is  possible,  however,  for  information  about  H  variables  to  leak 
to  an  outside  observer  who  can  observe  whether  c  halts,  aborts,  or 
fails  to  terminate,  or  how  long  c  takes  to  terminate.  See  [VS97a]  for 
some  approaches  to  eliminating  such  covert  information  flows. 


However,  the  language  considered  in  [VSI96]  is  sequen¬ 
tial,  while  mobile  programs  (such  as  Java  applets)  are  often 
multi-threaded.  For  this  reason,  it  is  important  to  extend 
our  analysis  to  deal  with  a  multi-threaded  language  and  to 
see  how  the  noninterference  property  is  affected  by  the  pres¬ 
ence  of  concurrency.  This  is  the  main  goal  of  this  paper. 

We  begin  with  an  example  that  shows  that  the  type  sys¬ 
tem  of  [VSI96]  is  no  longer  sufficient  to  ensure  noninterfer¬ 
ence  if  we  extend  our  language  with  concurrent  threads  that 
communicate  via  a  shared  memory.  The  program,  which 
consists  of  three  threads,  is  given  in  Figure  1.  Assume  that 
PIN  :  H  var  and  result  :  L  var.  Then  each  of  the  threads  in 
this  program  can  be  typed  under  the  type  system  of  [VSI96]. 
(The  typing  gives  triggerO  and  triggerl  type  H  var,  and 
maintrigger  and  mask  type  L  var.) 

But,  if  the  program  is  run  in  a  memory  where  initially 
maintrigger  =  0,  triggerO  =  0,  triggerl  =  0,  result  = 
0,  mask  is  a  power  a  2,  and  PIN  is  an  arbitrary  natural  num¬ 
ber  less  twice  mask,  then,  assuming  that  scheduling  is  fair 
(i.e.  each  thread  is  scheduled  infinitely  often),  the  program 
eventually  halts  with  the  value  of  PIN  copied  into  result. 
Thus  the  noninterference  property  is  violated. 

To  restore  the  noninterference  property  in  this  concur¬ 
rent  setting,  we  impose  two  new  restrictions  on  the  typing 
of  while  loops:  we  require  that  the  guard  of  a  while  loop 
have  type  L,  and  we  require  the  while  loop  itself  to  get  type 
L  cmd.  The  new  restrictions  succeed  in  ruling  out  the  above 
program — since  triggerO  and  triggerl  have  type  H ,  they 
cannot  be  used  in  the  guards  of  the  while  loops  in  threads 
a  and  8. 

In  the  next  three  sections,  we  develop  these  ideas  pre¬ 
cisely,  proving  that  the  new  restrictions  on  while  loops  are 
sufficient  to  restore  the  noninterference  property  for  multi¬ 
threaded  programs. 

3  Syntax  and  Semantics 

Threads  are  written  in  the  simple  imperative  language: 

( phrases )  p  ::=  e  \  c 

( expressions )  e  ::=  x  \  n  |  ei  +  ei  \ 

ei  —  ei  |  e\  =  e-2  |  ... 

( commands )  c  ::=  x  :=  e  \  ci;c2  | 

if  e  then  c i  else  C2  | 
while  e  do  c 

Metavariable  x  ranges  over  identifiers  and  n  over  integer 
literals.  Integers  are  the  only  values;  we  use  0  for  false  and 
nonzero  for  true.  Note  that  expressions  are  all  pure  (i.e. 
they  do  not  cause  side  effects)  and  total  (i.e.  they  do  not 
contain  partial  operations  like  division). 

The  concurrent  systems  that  we  consider  here  consist 
simply  of  a  set  of  commands  (the  threads)  that  run  concur¬ 
rently;  we  do  not  consider  facilities  for  creating  new  threads. 
Following  the  approach  taken  in  Cliff  Jones’s  ko3X  [Jon96], 
we  model  a  system  of  threads  with  an  object  map  O,  which 
is  simply  a  finite  function  from  thread  identifiers  (a,  j3,  . . .  ) 
to  commands.  In  addition,  there  is  a  single  global  memory 
y,  shared  by  all  threads,  that  maps  identifiers  to  integers. 
(Note  that  in  this  simple  context,  we  don’t  need  to  distin¬ 
guish  identifiers  from  locations.)  The  only  way  that  threads 
can  interact  is  via  the  shared  memory. 

In  this  paper,  we  assume  for  simplicity  that  expressions 
are  evaluated  atomically.  Thus  we  simply  extend  a  memory 
y  in  the  obvious  way  to  map  expressions  to  integers,  writing 
y(e)  to  denote  the  value  of  expression  e  in  memory  y.  Note 
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•  Thread  a: 

while  mask  ! =  0  do 

while  triggerO  =  0  do 

result  :=  result  I  mask;  //  bitwise  ’or’ 
triggerO  :=  0; 

maintrigger  : =  maintrigger+1 ; 
if  maintrigger  =  1  then  triggerl  :=  1 

•  Thread  j3: 

while  mask  ! =  0  do 

while  triggerl  =  0  do 

result  :=  result  &  "mask;  //  bitwise  ’and’  with  the  complement  of  mask 
triggerl  :=  0; 

maintrigger  : =  maintrigger+1 ; 
if  maintrigger  =  1  then  triggerO  :=  1 

•  Thread  7: 

while  mask  ! =  0  do 

maintrigger  :=  0; 
if  (PIH  &  mask)  =  0  then 
triggerO  :=  1 

else 

triggerl  :=  1; 
while  maintrigger  ! =  2  do 

mask  : =  mask  /  2 ; 
triggerO  : =  1 ; 
triggerl  :=  1 


Figure  1:  A  multi-threaded  program  that  leaks  information 
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that  pfe)  is  always  defined,  provided  that  every  identifier 
occurring  in  e  is  in  the  domain  of  p,  which  will  always  be 
the  case  if  e  is  well  typed. 

As  in  Gunter  [Gun92],  we  define  the  semantics  of  com¬ 
mands  via  transitions: 

(update)  x  €  dom(p) 

(x  :=  e, /*)— :=  //(e)] 

(sequence)  (ci,p)—^p' 

(ci;c2,//.)-4(c2,//) 

(ci  ,  // )  ~~A  (c)  ,  pf ) _ 

(ci;c2,/u.)-4(c'1;c2,/i') 

(branch)  p(e)  nonzero 

(if  e  then  ci  else  C2,  p)  — -A(ci,  p) 

M(e)  =  0 _ _ _ 

(if  e  then  ci  else  C2,/() — >(c2,p) 

(loop)  p(e)  =  0 

(while  e  do  c, p)  — s-+p 

p(e)  nonzero 

(while  e  do  c, //)— ^a(c;  while  e  do  c, //) 

These  rules  define  a  transition  relation  — on  configura¬ 
tions.  A  configuration  is  either  a  pair  (c,  //)  or  simply  a 
memory  p.  In  the  first  case,  c  is  the  command  yet  to  be 
executed;  in  the  second  case,  the  command  has  terminated, 
yielding  final  memory  p.  We  write  — for  the  fc-fold  self 
composition  of  — -t,  and  — for  the  reflexive,  transitive 
closure  of  — ^A. 

Next  we  have  two  rules  specifying  the  global  transitions 
that  can  be  made  by  a  system  of  threads: 

(global)  O(a)  = c 

(c,p)^p _ 

[0,p)-^{0  -  a,p) 

O(a)  =  c 

(c,//)-4(c',//') _ 

(0,p)^(0[a:=c'],p') 

The  semantics,  at  the  global  level,  is  thus  purely  nondeter- 
ministic.  (At  this  point,  we  don’t  even  require  that  schedul¬ 
ing  be  fair.)  How  to  implement  this  semantics  is  an  open 
question;  this  will  be  discussed  further  in  Sections  7  and  8. 

4  The  Type  System 

Here  are  the  types  used  by  our  type  system: 

( data  types)  t  ::=  L  \  H 

( phrase  types)  p  ::=  r  |  r  var  |  r  cmd 

For  simplicity,  we  limit  the  security  classes  here  to  just  L 
and  H;  it  is  possible  to  generalize  to  an  arbitrary  partial 
order  of  security  classes. 

Our  type  system,  whose  rules  are  given  in  Figure  2,  al¬ 
lows  us  to  prove  typing  judgments  of  the  form  7  b  p  :  p  as 
well  as  subtyping  judgments  of  the  form  pi  C  p2.  Here  7 
denotes  an  identifier  typing ,  which  is  a  finite  function  from 
identifiers  to  phrase  types. 


If  7  h  c  :  p  for  some  p,  then  we  say  that  c  is  well  typed 
under  7.  Also,  if  O(a)  is  well  typed  under  7  for  every  a  E 
dom(0 ),  then  we  say  that  O  is  well  typed  under  7. 

As  compared  with  the  type  system  of  [VSI96],  the  typ¬ 
ings  of  while  loops  are  here  restricted  in  two  ways:  first, 
the  guard  of  a  while  loop  must  have  type  L ,  and  second, 
the  while  loop  itself  can  only  get  type  L  cmd. 

5  Type  Soundness 

We  begin  with  three  lemmas  that  establish  the  key  proper¬ 
ties  ensured  by  the  type  system;  these  lemmas  are  then  used 
to  prove  that  well-typed  programs  have  the  noninterference 
property. 

Lemma  5.1  (Simple  Security)  If  7  b  e  :  L,  then  every 
identifier  in  e  has  class  L. 

Proof.  By  induction  on  the  structure  of  e.  □ 

Lemma  5.2  (Confinement)  If  7  he:  H  cmd,  then  every 
identifier  assigned  to  in  c  has  class  H ,  and  c  is  guaranteed  to 
terminate  successfully  from  any  memory  p  where  dom{p)  = 
dom{"() . 

Proof.  By  induction  on  the  structure  of  c,  and  using  the  fact 
that  c  cannot  contain  any  while  loops.  □ 

Lemma  5.3  (Subject  Reduction)  If  7  b  c  :  r  cmd  and 

(c,  //)— -t(c' ,  fi  ),  then  7  h  c  \  t  cmd. 

Proof.  By  induction  on  the  structure  of  c. 

If  c  is  of  the  form  ci ;  C2 ,  then  it  follows  that  7  h  q  : 
r  cmd  and  7  h  C2  :  r  cmd.  (The  argument  for  this  is  com¬ 
plicated  somewhat  by  the  presence  of  subtyping.)  If  the 
transition  is  by  the  second  rule  (sequence), 

(ci,p)-4(c'i,p') _ 

(ci;c2,/t)-4(c'1;c2,p.') 

then  by  induction  7  h  c]  :  r  cmd,  and  so  by  rule  (compose) 
7  b  c[’c2  :  t  cmd.  If  the  transition  is  by  the  first  rule 
(sequence),  the  argument  is  simpler. 

If  c  is  of  the  form  while  e  do  ci,  then  r  must  be  L,  and 
we  must  have  7  h  ci  :  L  cmd,  and  so  7  h  ci;  while  e  do  ci  : 
L  cmd. 

The  case  of  if  e  then  ci  else  C2  is  similar.  □ 

We  also  need  a  lemma  about  the  execution  of  a  sequential 
composition: 

Lemma  5.4  If(c\,p)  — {c'i,p!),  then  (<5ij  c%,p)  — 

s  k  $  k 

(ci ;  C2,  p).  If  (ci,p)  — »  p  ,  then  In  (c.!,/'l  — »  ( c2,p ')■ 
Proof.  By  induction  on  k.  □ 

Definition  5.1  Given  an  identifier  typing  7,  we  say  that 
memories  p  and  v  are  equivalent,  written  p^^v,  if  p,  v, 
and  7  have  the  same  domain  and  p  and  v  agree  on  all  L 
identifiers. 

We  also  say  that  two  commands  are  equivalent  if  this  can 
be  shown  from  the  following  three  rules: 

1.  If  c  =  c' ,  then  c~7c' . 

2.  If  c  and  d  have  type  H  cmd,  then  c~-,d. 
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(ident) 

lix)  =  p 

7  h  x  :  p 

(int) 

7  h  n  :  T 

(r-val) 

7  h  e  :  r  var 

7  h  e  :  T 

(sum) 

7  h  G  :  r,  7  h  e2  :  r 

7  h  ei  +  e2  :  r 

(assign) 

7  h  x  :  T  var,  7  h  e  :  T 

7  h  x  :=  e  :  r  cmd 

(compose) 

7  h  Ci  :  r  cmd,  7  h  C2  :  r 

cmd 

7  h  ci ;  C2  :  r  cmd 

(IF) 

7  h  e  :  T,  7  h  ci  :  r  cmd, 

7  F  c2 

7  h  if  e  then  ci  else  C2  : 

r  cmd 

(while) 

7  h  e  :  L,  7  he  :  L  cmd 

7  h  while  e  do  c  :  L  cmd 

(base) 

LCH 

(reflex) 

in 

(cmd  -  ) 

T 1  C  T2 

T2  cmd  C  t 1  cmd 

(subtype) 

7  '  /'  :  /'i  •  pi  C  p2 
"f\~p.p2 

Figure  2:  Typing  and  subtyping  rules 


3.  If  c~7c7  and  d~7d' ,  then  c;  d~7c' ;  d! . 

Finally,  we  extend  equivalence  to  configurations  by  defining 
(r.  // ) ~ -  (d.  i')  if  c~-,d  and  ju~7p. 

Why  do  we  need  a  notion  of  equivalence  on  commands? 
Well,  we  are  trying  to  show  that  executing  a  command  twice, 
from  two  equivalent  memories,  leads  to  equivalent  memories. 
But  to  prove  this  property  by  induction  on  the  number  of 
transitions,  it  is  necessary  to  deal  with  the  fact  that  the  two 
executions  can  proceed  quite  differently,  because  condition¬ 
als  with  H  guards  need  not  follow  the  same  branches  in  the 
two  executions.  For  this  reason,  we  must  prove  a  more  gen¬ 
eral  property:  roughly  speaking,  equivalent  configurations 
go  to  equivalent  configurations. 

Remark.  The  need  for  clause  3  in  the  above  definition 
can  be  seen  from  the  following  example.  Suppose  x  :  H , 
d  :  L  cmd ,  and  p^^v.  If  p  and  v  disagree  about  the  value 
of  x,  then  the  command  (if  x  =  0  then  ci  else  C2);  d  could 
go  to  (ci;  d ,  p)  under  /a  and  go  to  (C2;  d ,  v)  under  v.  Thus  we 
need  ci;d~7C2;d,  but  these  don’t  have  type  H  cmd.  End 
of  Remark. 

Theorem  5.5  (Sequential  Noninterference)  Suppose  c 
and  d  are  well  typed  under  7  and  (c,  p)~1{d,v).  If  (c,  p)  — ^ 
( c  ,p ’),  then  there  exists  ( d',v ')  such  that  {d,v)  — ^  [d!  ,v) 
and  (c1 ,  p  )^1(d' ,v  ) .  And  if  (c,p)  — ^  p  ,  then  there  exists 
v’  such  that  (d,  v)  — ^  v'  and  p' ~7;/ . 

Proof.  By  induction  on  the  structure  of  c. 

We  begin  by  dealing  with  the  case  when  c  and  d  both 
have  type  H  cmd.  In  this  case,  by  the  Confinement  Lemma 
c  does  not  assign  to  any  variables  of  type  L.  Therefore, 


if  (c,  p)  — s-^(c',  p  ),  then  we  can  let  (d!  ,v)  be  (d,  u)  since 

(d,  v)—t  (d,v)  and  (c',  ju')~7  (d,  v).  This  is  because  c  must 
also  have  type  H  cmd  by  the  Subject  Reduction  Lemma. 
If,  instead,  the  transition  is  (c,  p)— -tp1 ,  then  we  can  appeal 
again  to  the  Confinement  Lemma  to  get  that  neither  c  nor 
d  assigns  to  any  variables  of  type  L ,  and  that  there  exists  v 
such  that  (d,v)—I+  v  . 3  Since  p  ~7z/ ,  we’re  done. 

We  now  deal  with  the  case  when  c  and  d  do  not  both 
have  type  H  cmd  by  considering  in  turn  the  possible  forms 
of  c: 

Case  x  :=  e.  Since  c  and  d  do  not  both  have  type  H  cmd , 
we  must  have  c  =  d,  and  therefore  c  does  not  have 
type  H  cmd.  Hence  x  must  have  type  L  var  and  e 
must  have  type  L.  So,  by  the  Simple  Security  Lemma, 
every  identifier  in  e  has  class  L.  Therefore,  since  p~^v, 
we  have  p{e)  =  v(e)  and  p[x  :=  p(e)]~^v[x  :=  v(e)\. 

Case  ci;  C2.  Since  c  and  d  do  not  both  have  type  H  cmd,  d 
must  have  the  form  di;d.2,  where  ci~7di  and  C2~7d2- 
So  if  (ci,  p)— ,  p  ),  then  by  induction  there  ex¬ 
ists  (d’i,  v)  such  that  (di,  (d[,  v)  and  (ci,  p)^^ 

(di,//).  So  by  Lemma  5.4,  (di;  d2,  ^)— -t  (d[;  d2,v'). 
And,  by  clause  3  of  the  definition  of  ~-7,  we  have 
(ci ;  C2,  p  )~7  (d[;  d2,v' )■  Similarly,  if  (ci,  p)—^rp,  then 
by  induction  there  exists  v'  such  that  (di,  v)—t  v'  and 
p'^^v'.  Again  by  Lemma  5.4,  {di\d2,v)— (d2,v'). 

3We  remark  that  the  proof  would  break  down  here  if  while  loops 
were  typed  as  in  [VSI96].  Under  those  rules,  d  could  contain  while 
loops,  and  hence  might  not  be  assured  of  terminating. 
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Case  if  e  then  ci  else  ci-  Since  c  and  d  do  not  both  have 
type  H  cmd ,  we  must  have  c  =  d,  and  c  does  not  have 
type  H  cmd.  Hence  e  :  L.  As  above,  this  implies  that 
p(e)  =  v(e).  So  if  (if  e  then  ci  else  C2,  p)  — //), 
then  /((e)  =  i/(e)  is  nonzero,  so 

(if  e  then  ci  else  02, ’t')— ^-t(ci ,  v). 

And  if  (if  e  then  ci  else  (••:./()  >(<;■>.  p).  then 

(if  e  then  ci  else  cj,  v)— ^(c2,  v). 

Case  while  e  do  ci .  Since  while  loops  cannot  have  type 
H  cmd ,  we  must  have  c  =  d,  and  e  :  L.  Again,  this  im¬ 
plies  that  /x(e)  =  i/(e).  So  if  (while  e  do  ci,p)  — ^-t/(, 
then  (while  e  do  ci ,  v)-^-¥v.  And  if 

(while  e  do  ci ,  ;  while  e  do 

then 

(while  e  do  ci ,  (z)-^(ci ;  while  e  do  ci,iz). 

□ 

Remark.  The  Sequential  Noninterference  theorem  says 
that  if  (c,  /t)~7  (d,  k)  and  (c,  /t)  reaches  a  configuration  in  one 
step,  then  ( d ,  //)  reaches  an  equivalent  configuration  in  zero 
or  more  steps.  This  bound  cannot  be  strengthened.  For 
example,  suppose  that  c  is  ci;c2  and  d  is  di;c2,  where  ci 
and  d\  have  type  H  cmd ,  but  C2  has  type  L  cmd.  Suppose 
further  that  (ei,/t)  goes  to  p  in  one  step,  but  (di,v)  goes 
to  v'  in  50  steps.  Then  (ci;c2,/()  goes  in  one  step  to  (c2,p'). 
But  < r / 1 ;;  C2,  v)  takes  50  steps  to  get  to  (c2,  v').  And  we  need 
di  to  run  to  completion  in  order  to  get  the  required  program 
equivalence,  since  C2  is  not  equivalent  to  d'i ;  C2  for  any  d'i , 
under  our  definition  of  ~7 .  End  of  Remark. 

We  now  wish  to  apply  the  Sequential  Noninterference 
Theorem  to  establish  a  Concurrent  Noninterference  Theo¬ 
rem.  We  begin  with  a  lemma,  which  depends  crucially  on 
our  nondeterministic  scheduling,  that  shows  that  any  execu¬ 
tion  of  a  thread  can  be  “lifted”  to  an  execution  of  the  global 
system: 

Lemma  5.6  (Global  Execution)  Suppose  O(a)  =  c.  If 
(c,p)—^(c',p'),  then  (0,p)-^-t  \o[a  :=  c\,p).  And  if 
(c,  n)—}  p  ,  then  (O,  p)——t  ( O  —  a,  p  ) . 

Proof.  By  induction  on  k. 

If  k  =  0,  then  (c,  p)  =  ( c  ,  p '),  so  ( 0[a  :=  c],p)  = 
( 0,p ).  Hence  (O,  p)-^  (0[a  :=  c'],  p). 

s  k-\-\ 

For  the  inductive  step,  if  (c, /() — >  (c  ,p),  then  there 

exists  ( c" ,  p ")  such  that  {c.p)  >(<■". p")  >(<:'. p').  By 

induction,  (0,p)-^r  (O[o  :=  c"],p").  And  by  the  second 
rule  (global), 

(O[o  :=  c"].  p" ) — —t(0[o  :=  c"\[a  :=  c],p). 

Since  0[a  :=  c'\[a  :=  c'\  =  O[o  :=  c'],  it  follows  that 
(0,/()-^t+  {0[a:=c],p). 

The  case  where  ( c,p ) — >  p  is  similar.  □ 


Remark.  This  lemma  remains  true  if  we  assume  that 
scheduling  is  fair,  since  we  are  dealing  only  with  finite  com¬ 
putations  here.  But  if  we  assume  hounded  fairness,  so  that 
there  is  a  fixed  bound  b  on  the  number  of  transitions  a  thread 
can  make  before  another  thread  gets  a  turn,  then  the  lemma 
holds  only  for  k  <  b.  End  of  Remark. 

Definition  5.2  Oi~7C>2  if  dom(0\)  =  dom(0 2)  and  for 
all  a  £  dom{0 1),  Oi  (a)~-,02(o) .  Also,  (Oi ,  /()~7(02,  v)  if 
0i~702  and  p~1v. 

Corollary  5.7  (Concurrent  Noninterference)  Suppose 
0 1  and  O2  are  well  typed  under  7  and  (Oi,  /t)~7  (O2,  v)  ■ 
If  (Oi,  p)-^(0'i ,  p),  then  there  exists  {O^v1)  such  that 
(02,(z)— 4  (O2,  v')  and  (0i,/t')~7(02,iz')- 

Proof.  If  (Oi ,  p)  — —t(0'i ,  p1'),  then  (by  inspection  of  the  rules 
(global))  there  exists  a  such  that  Oi(a)  =  c  and  either 

1.  (c,  p)  — ,  p  )  and  0[  =  Oi[o  :=  c'\,  or  else 

2.  (c,  /()  — —t p  and  0[  =  Oi  —  a. 

Let  d  =  02(a).  Then  (c,  p)~~,(d,  v),  since  (Oi ,  /t)~7 (O2,  v). 
So,  in  the  first  case,  by  the  Sequential  Noninterference  The¬ 
orem  there  exists  (d' ,v)  such  that  (d,v)-^>  (d' ,v')  and 
(c  ,  /(,)~7  (d1 ,  v' ).  Hence,  by  the  Global  Execution  Lemma, 
(02,1')-^  (O2  [cv  :=  d!],  v' ) .  Finally, 

(Oi  [a  :=  c],  /u')~7(02[o  :=  d!],  v). 

The  second  case  is  similar.  □ 

Let  {}  denote  the  empty  object  map.  We  can  give  a  final 
corollary: 

Corollary  5.8  Suppose  that  O  is  well  typed  under  7  and 
/i~7(z.  If  (O,  p)  — ({},//),  then  there  exists  v'  such  that 
({},(z')  and  p  . 

Proof.  By  an  easy  generalization  of  the  Concurrent  Non¬ 
interference  Corollary,  it  follows  that  there  exists  (O' ,v') 
such  that  (0,v)-^r  (O' ,v')  and  ({}, /(')~7(0', ;/').  Then 
O'  =  {}  by  definition  of  ~7.  □ 

6  Adding  a  Clock  to  the  Language 

Many  languages  include  a  system  clock  that  can  be  read  by 
a  running  program;  for  instance,  Java  includes  a  function 
System.  currentTimeMillis  () .  One  would  expect  that  such 
a  clock  would  have  implications  for  secure  information  flow, 
since  it  makes  timing  information  observable  internally.  In 
this  section,  we  explore  this  issue. 

To  include  a  clock,  we  use  a  special  identifier  t,  initially 
0,  which  tells  the  number  of  transition  steps  that  have  been 
made  in  the  current  program  execution.  We  can  make  t 
read-only  by  giving  it  either  type  L  or  H,  rather  than  L  var 
or  H  var.  We  must  modify  the  semantics  of  some  commands 
to  update  f  appropriately;  the  modified  transitions  are  given 
in  Figure  3. 

Now,  if  we  assume  t  :  L,  then  we  clearly  run  into  trouble 
with  the  noninterference  property.  For  example,  suppose 
that  x  :  H ,  y  :  L,  and  c  :  H  cmd  is  a  command  that  takes  20 
steps  to  finish.  Consider  the  following  program,  which  has 
just  one  thread: 
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(update)  x  6  dom(p) 

( x  :=  e,p)-^-p[x  :=  p(e),t.  :=  p(t.)  +  1] 

(branch)  p(e)  nonzero 

(if  e  then  ci  else  jj£,  p)—>(ci,  fi[t.  :=  p(t)  +  1]) 

P(e)  =  0 _ _ _ 

(if  e  then  ci  else  C2,  /() — >(c2,  p[t  '■=  //(/)  +  1]) 

(LOOP)  /[((e)  =  0 

(while  e  do  c,  fi)-^p[t  :=  p(t)  4-  1] 

/[((e)  nonzero 

(while  e  do  c,  while  e  do  c,  p[t  :=  p(t)  -f  1]) 

Figure  3:  Modified  transitions  to  maintain  a  clock  t 


if  x  =  1  then  c; 

if  t  <  10  then  y  :=  0  else  y  :=  1 

Assuming  that  x  is  either  0  or  1  initially,  this  program  copies 
x  into  y.  By  checking  the  value  of  t,  the  program  can  de¬ 
termine  whether  c  was  executed  or  not,  which  in  turn  tells 
whether  x  =  1  or  not. 

But  if  we  assume,  instead,  that  t  :  H,  then  the  above 
program  is  ill-typed,  because  the  branches  of  the  second 
conditional  do  not  have  type  H  cmd.  And,  indeed,  if  t  :  H } 
then  the  proof  of  Theorem  5.5  still  goes  through,  and  so  the 
noninterference  property  is  preserved. 

7  Other  Scheduling  Policies 

The  semantics  of  concurrency  given  by  rule  (global)  is 
purely  nondeterministic;  the  rule  simply  says  that  at  ev¬ 
ery  step,  any  thread  can  be  selected  to  run  for  a  step.  It 
is  important  to  understand  that  the  noninterference  results 
of  the  last  section  depend  crucially  on  this  nondetermin¬ 
ism.  For  example,  Corollary  5.8  says  that  if  /t(~7u  and  there 
is  some  way  of  scheduling  the  threads  of  (0,p)  that  leads 
to  termination,  then  there  is  some  way  of  scheduling  the 
threads  of  (O,  v)  that  leads  to  an  equivalent  result.  But  the 
two  schedules  can  be  very  different!  In  particular,  even  if  the 
first  schedule  treats  all  threads  equally  (in  the  sense  that  it 
gives  each  thread  a  roughly  equal  amount  of  CPU  time),  the 
second  schedule  might  have  to  greatly  favor  one  thread  over 
the  others.  Therefore,  if  we  impose  additional  constraints 
on  the  way  scheduling  is  done,  we  may  falsify  the  Global 
Execution  Lemma  and  hence  the  noninterference  property.4 

For  example,  suppose  that  scheduling  is  done  by  round- 
robin  time  slicing,  with  a  time-slice  of  b  steps.  Let  x  :  H 
and  y  :  L  and  consider  the  following  two  threads: 

•  Thread  a: 

if  x  =  1  then  c; 

y  :=  1 

•  Thread  ft: 
y  :=  0 

4T1ius  our  situation  is  quite  different  from  the  usual  one  in  which 
one  proves  the  correctness  of  a  concurrent  program  with  respect 
to  a  nondeterministic  scheduler.  There,  one  can  immediately  say 
that  the  program  is  correct  with  respect  to  any  scheduler  that  one 
might  care  to  implement,  because  any  schedule  produced  by  an  imple¬ 
mented  scheduler  could  have  been  produced  by  the  nondeterministic 
scheduler. 


Suppose  further  that  c  :  H  cmd  is  a  command  that  takes 
longer  than  b  steps  to  finish.  If  p(x)  =  0,  v{x)  =  1,  and 
p(y)  =  viy)  =  0,  then  /u~7;y.  And  from  p,  we  can  terminate 
in  a  state  where  y  =  0,  but  from  v  we  cannot;  from  v,  we 
can  only  terminate  in  a  state  where  y  =  1. 

In  terms  of  our  proofs,  here’s  what  is  going  on: 

((if  x  =  1  then  c);  y  :=  l,/u)-4(?/  :=  1,/u), 

so  by  the  Sequential  Noninterference  theorem  there  exists  v 
such  that 

((if  x  =  1  then  c);  y  :=  l,u)-4  {y  :=  l,i/), 

and  p^1v' .  But,  although  (O,  p)-^(0[a  :=  (y  :=  l)],/x),  it 
is  not  the  case  that  (O,  v)-^r  ( 0[a  :=  (y  :=  1)],  u'),  because 
the  time-slicing  scheduler  will  not  let  thread  a  run  for  such 
a  long  time  without  giving  a  turn  to  thread  3. 

Another  approach  to  scheduling  is  probabilistic.  One 
might  attempt  to  approximate  the  effect  of  rule  (global) 
by  flipping  coins  at  each  step  to  select  the  next  thread  to 
run.  While  such  an  implementation  is  in  some  ways  faithful 
to  rule  (global),  the  adoption  of  a  probabilistic  seman¬ 
tics  makes  it  possible  to  create  probabilistic  covert  channels 
[Gra.90],  which  cannot  be  addressed  without  refining  the  no¬ 
tion  of  noninterference.  This  point  is  discussed  in  more  de¬ 
tail  in  Section  8. 

To  preserve  noninterference  in  the  face  of  an  arbitrary 
scheduler,  it  appears  necessary  to  require  the  guards  of  con¬ 
ditionals  to  have  type  L.  If  this  is  done,  we  can  strengthen 
the  Sequential  Noninterference  Theorem  to  the  following 
form: 

Theorem  7.1  (Lockstep  Execution)  Suppose  c  is  well 
typed  under  7  and  /u~7u.  If  (c,  p)— ^(c,  fi),  then  there 
exists  v  such  that  (c,v)—^(c',v')  and  /'/~7(/.  And  if 
(c, /[()— ,  then  there  exists  v  such  that  (c,v)—^v  and 

I  I 

fl  . 

This  Lockstep  Execution  result  is  strong  enough  to  estab¬ 
lish  Concurrent  Noninterference,  regardless  of  how  schedul¬ 
ing  is  done.  Anything  done  under  p  can  now  be  exactly 
mirrored  under  v.  Also,  Lockstep  Execution  implies  that 
we  can  add  a  clock  t  and  even  give  it  type  L,  since  program 
timing  now  cannot  depend  on  the  values  of  H  variables.  Un¬ 
fortunately,  restricting  conditionals  in  this  way  is  likely  to 
be  quite  burdensome  in  practice. 

On  the  other  hand,  it  can  be  useful  for  guarding  against 
timing  attacks.  Kocher,  for  example,  describes  a  timing 
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attack  on  RSA  modular  exponentiation  to  learn  a  private 
key  [Koc96].  Such  attacks  are  possible  by  merely  knowing 
the  source  code  for  an  algorithm.  Typing  conditionals  as 
restrictively  as  while  loops  rejects  code  susceptible  to  this 
kind  of  attack. 

8  A  Closer  Look  at  Noninterference 

Our  noninterference  property  basically  says  that  the  final 
values  of  low  variables  are  independent  of  the  initial  val¬ 
ues  of  high  variables.  More  precisely,  it  says  that  changing 
the  initial  values  of  high  variables  cannot  affect  the  set  of 
possible  final  values  of  low  variables.  Hence,  observing  the 
final  values  of  low  variables  cannot  reveal  anything  about 
the  initial  values  of  high  variables. 

But  consider  the  following  example,  which  is  given  by 
McLean  [McL90].  Let  x  be  a  high  variable  whose  value  is 
between  1  and  100  and  let  y  be  a  low  variable.  Consider  the 
following  two  threads: 

•  Thread  a: 
y  :=  x 

•  Thread  0: 

y  :=  rand(lOO) 

where  rand  (100)  returns  a  random  integer  between  1  and 

100. 

Now,  this  program  satisfies  our  noninterference  property: 
regardless  of  the  value  of  x,  the  final  value  of  y  can  be  any 
integer  between  1  and  100.  But  this  program  doesn’t  seem 
to  be  secure!  If  we  were  to  run  the  program  repeatedly,  we 
would  expect  a  sequence  of  final  values  for  y  something  like 

75,22,12,22,22,93,4,22,... 

and  we  would  feel  quite  confident  that  (in  this  case)  the 
value  of  x  is  22. 

How  can  this  be  explained?  The  answer  is  that  we  have 
implicitly  changed  the  semantics  of  our  language  from  the 
purely  nondeterministic  semantics  of  rule  (global)  to  some 
kind  of  probabilistic  semantics.  In  a  nondeterministic  se¬ 
mantics,  outcomes  are  either  possible  or  impossible ,  with 
no  further  distinction.  But  in  a  probabilistic  semantics, 
outcomes  occur  according  to  some  probability  distribution , 
which  makes  it  possible  to  make  probabilistic  inferences. 

In  our  example,  if  we  assume  that  each  thread  has  an 
equal  probability  of  being  scheduled  at  each  step  and  that 
rand  (100)  generates  all  numbers  in  the  range  1  to  100  with 
equal  probability,  then  we  can  see  that  the  final  value  of  y 
will  be  the  initial  value  of  x  with  probability  101/200,  and 
will  be  any  other  number  between  1  and  100  with  probabil¬ 
ity  1/200.  Hence  we  can  be  confident  of  correctly  guessing 
the  initial  value  of  x  by  running  the  program  repeatedly  and 
picking  the  most  common  final  value  of  y.  To  rule  out  such 
probabilistic  inferences,  we  would  need  a  more  refined  notion 
of  noninterference  that  requires  that  the  probability  distri¬ 
bution  of  the  final  value  of  y  be  independent  of  the  initial 
value  of  x.  The  program  would  not  satisfy  such  a  probabilis¬ 
tic  notion  of  noninterference,  because  changes  to  the  initial 
value  of  x  do  change  the  distribution  of  the  final  value  of  y. 

Thus  we  can  see  that  the  appropriate  formulation  of  the 
noninterference  property  depends  on  the  kind  of  language 
being  considered.  In  all  cases,  the  idea  is  that  the  final  val¬ 
ues  of  low  variables  are  independent  of  the  initial  values  of 


high  variables.  For  a  deterministic  language,  this  means  that 
changing  the  initial  values  of  high  variables  cannot  change 
the  final  values  of  low  variables.  For  a  nondeterministic  lan¬ 
guage,  as  considered  in  this  paper,  it  means  that  changing 
the  initial  values  of  high  variables  cannot  change  the  set 
of  possible  final  values  of  low  variables.  And  for  a  proba¬ 
bilistic  language,  it  means  that  changing  the  initial  values 
of  high  variables  cannot  change  the  distribution  of  possible 
final  values  of  low  variables.6 

It  can,  of  course,  be  argued  that  a  nondeterministic  se¬ 
mantics  as  used  in  this  paper  is  unrealistic,  because  any 
real  implementation  would  display  probabilistic  behavior. 
It  is  perhaps  worth  remarking  that  a  nondeterministic  se¬ 
mantics  can  be  regarded  as  an  abstraction  of  a  probabilis¬ 
tic  semantics  in  which  one  equates  “possible”  with  “occurs 
with  nonzero  probability”.  For  instance,  an  implementa¬ 
tion  of  rule  (global)  that  flips  coins  at  each  step  to  decide 
which  thread  to  run  has  the  property  that  each  thread  has 
a  nonzero  probability  of  being  selected  at  each  step.  Indeed, 
any  terminating  execution  possible  under  rule  (global)  has 
a  nonzero  probability  of  occurring  in  the  implementation. 
Therefore,  Corollary  5.8  does  hold  for  this  implementation. 
However,  one  has  to  be  careful  with  this  view  of  possibility. 
Though  the  corollary  assures  us  that,  under  such  an  im¬ 
plementation,  one  can  never  be  certain  of  the  initial  values 
of  high  variables  based  on  observing  the  final  values  of  low- 
variables,  it  does  not  mean  that  one  cannot  guess  the  initial 
values  with  high  probability. 

It  is  also  worth  remarking  that  thread  a  in  the  example 
above  is  rejected  by  our  type  system.  This  suggests  that 
well-typed  programs  in  our  system,  if  given  a  probabilistic 
semantics,  might  perhaps  satisfy  some  sort  of  probabilistic 
noninterference  property.  But  it  is  easy  to  see  that  our  type 
system  would  not  rule  out  probabilistic  timing  channels.  For 
example,  suppose  x  is  a  high  varible  whose  value  is  either  0 
or  1,  y  is  a  low-  variable,  and  c  is  a  high  command  that  takes 
a  long  time  to  execute.  Consider  the  following  two  threads: 

•  Thread  a: 

if  x  =  1  then  (c ; c) ; 

y  :=  1 

•  Thread  f3: 

c ; 

y  :=  0 

If  thread  scheduling  works  by  flipping  a  coin  at  each  step 
to  decide  which  thread  to  run,  then  with  high  probability 
the  two  threads  run  at  about  the  same  rate.  Hence,  with 
high  probability  the  value  of  x  ends  up  being  copied  into 
y.  Extending  our  type  system  to  deal  with  a  probabilistic 
language  remains  an  area  for  future  study. 

Finally,  it  is  well  know-n  that  in  some  cases  noninterfer¬ 
ence  is  too  restrictive.  In  particular,  noninterference  cannot 
accommodate  information  downgrading.  For  example,  infor¬ 
mation  is  effectively  downgraded  wdien  it  is  encrypted.  The 

5In  the  security  literature,  there  have  been  many  noninterference- 
like  properties  proposed.  Noninterference  was  first  proposed  by 
Goguen  and  Meseguer  [GM82]  for  deterministic  systems.  Later, 
McCullough  [McC88]  proposed  Generalized  Noninterference  and  Re¬ 
strictiveness  for  nondeterministic  systems,  and  Gray  [Gra90,  Gra91] 
proposed  P-Restrictiveness  and  Information  Flow  Security  for  prob¬ 
abilistic  systems.  See  also  McLean  [McL90]  for  a  comparison  of 
some  of  these  properties,  and  Wittbold  and  Johnson  [WJ90]  for 
an  information-theoretic  account  of  possibilistic  and  probabilistic 
noninterference. 


problem  is  that  ciphertext  is  sensitive  to  changes  in  high 
cleartext,  yet  we  would  often  like  to  treat  the  ciphertext  as 
low.  This  is  a  clear  violation  of  noninterference  [McL90]. 

9  Related  Work 

Analyzing  code  for  various  security  properties  has  a  long 
history.  Denning  [Den75,  Den76,  DD77]  developed  a  form 
of  program  certification  for  detecting  secure  flow  violations 
in  code.  It  was  inspired  by  the  work  of  Bell  and  LaPadula 
[BL73],  Fenton  [Fen73],  and  Lampson  [Lam73],  among  oth¬ 
ers.  There  is  also  the  classic  operating  systems  protection 
work  of  Harrison,  Ruzzo,  and  Ullman  who  showed  that  the 
problem  of  determining  whether  a  program,  comprised  of 
simple  primitives  for  updating  an  access  matrix,  leaks  an 
access  right  is  undecidable  [HRU76].  See  also  [DDG+76] 
for  an  excellent  discussion  about  solvability  and  complexity 
issues  associated  with  formal  systems  for  reasoning  about 
program  security. 

More  recently,  there  is  the  work  of  He  and  Gligor  [HG92] 
who  describe  ways  to  eliminate  timing  channels  in  the  source 
code  of  trusted  computing  bases  using  an  automated  tool. 
Banatre,  Bryce,  and  Le  Metayer  [BBLM94]  attempt  to  treat 
secure  information  flow  in  a  nondeterministic  setting;  they 
give  a  compile-time  technique  for  detecting  flow  violations 
in  sequential  programs. 

Other  more  recent  efforts  are  more  closely  related  to  our 
work  in  that  they  too  attempt  to  characterize  some  sort  of 
security  analysis  as  a  formal  system  of  types.  Palsberg  and 
Orbask  [P095]  have  developed  a  system  to  manage  trust 
in  the  lambda  calculus.  It  is  not  clear  what  an  appropri¬ 
ate  notion  of  type  soundness  is  for  their  trust  system,  given 
that  explicit  coercions  between  trusted  and  untrusted  enti¬ 
ties  are  available  in  the  core  calculus.  Any  suitable  notion 
should  speak  to  security  in  some  way.  Abadi  [Aba97]  has 
developed  a  system  of  typing  rules  for  ensuring  secrecy  in 
cryptographic  protocols.  These  protocols  are  expressed  in 
an  extension  of  the  pi  calculus  called  spi.  Type  soundness  is 
that  of  testing  equivalence  between  two  terms  Pa  and  Pa' , 
where  a  and  a1  are  substitutions  of  values  for  variables  and 
P  is  a  well-typed  spi  term.  In  other  words,  no  other  spi  term, 
called  an  observer,  can  distinguish  Pa  from  Pa1.  Heintze 
and  Riecke  [HR98]  attempt  to  refine  Denning’s  analysis  us¬ 
ing  more  detailed  type  structure.  They  also  extend  their 
type  system  for  a  concurrent  language  but  do  not  treat  type 
soundness  in  this  case.  Finally,  Myers  and  Liskov  [ML97] 
describe  a  decentralized  approach  to  downgrading  informa¬ 
tion  in  a  secure  information  flow  setting,  but  its  soundness 
also  is  not  addressed.  Some  sort  of  formal  justification  for 
downgrading  is  needed. 

10  Conclusion 

It  is  clear  that  with  just  ordinary  thread  implementations, 
users  can  exploit  seemingly  innocuous  features  like  thread 
priorities  and  scheduling  to  easily  build  reliable  covert  chan¬ 
nels.  An  off-the-shelf  implementation  of  Java  is  more  than 
enough  here.  Furthermore,  the  bandwidth  of  such  channels 
is  not  an  issue,  for  private  keys  and  credit  card  numbers 
require  little  bandwidth.  A  truly  secure  programming  lan¬ 
guage  demands  fundament  al  changes  in  language  design  and 
an  understanding  of  the  relationship  between  semantics  and 
security. 
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